SIP-based VoIP traffic behavior profiling method

ABSTRACT

With the widespread adoption of SIP-based VoIP, understanding the characteristics of SIP traffic behavior is critical to problem diagnosis and security protection of VoIP services. A general methodology is provided for profiling SIP-based VoIP traffic behavior at several levels: SIP server host, server entity (e.g., registrar and call proxy) and individual user levels. Using SIP traffic traces captured in a production VoIP network, the characteristics of SIP-based VoIP traffic behavior in an operational environment is illustrated and the effectiveness of the general profiling methodology is demonstrated. In particular, the profiling methodology identifies anomalies due to performance problems and/or implementation flaws through a case study. The efficacy of the methodology in detecting potential VoIP attacks is also demonstrated through a test bed experimentation.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a divisional application of U.S. patent applicationSer. No. 11/540,893 filed Sep. 28, 2006 now U.S. Pat. No. 7,441,429 andentitled “SIP-based VoIP Traffic Behavior Profiling Method.”

BACKGROUND

1. Field

The present invention relates to computers and computer networks. Moreparticularly, the present invention relates to SIP-based VoIP trafficbehavior profiling method.

2. Description of Related Art

Voice over IP (VoIP) allows users to make phone calls over the Internet,or any other IP network, using the packet switched network as atransmission medium rather than the traditional circuit transmissions ofthe Public Switched Telephone Network (PSTN). VoIP has come a long waysince its first rudimentary applications provided erratic yet free phonecalls over the unmanaged Internet. VoIP technology has reached a pointof being comparable in terms of grade voice quality with traditionalPSTN yet consuming only a fraction of the bandwidth required by TDMnetworks. The maturity of VoIP standards and quality of service (QoS) onIP networks opens up new possibilities for carrier applications.Consolidation of voice and data on one network maximizes networkefficiency, streamlines the network architecture, reduce capital andoperational costs, and opens up new service opportunities. At the sametime, VoIP enables new multimedia service opportunities, such asWeb-enabled multimedia conferencing, unified messaging, etc, while beingmuch cheaper.

The session initiation protocol (SIP) is the Internet standard signalingprotocol for setting up, controlling, and terminating VoIP sessions. Inaddition to IP telephony, it can also be used for teleconferencing,presence, event notification, instant messaging, and other multimediaapplications. SIP-based VoIP services require infrastructure supportfrom entities such as SIP registrars, call proxies, and so forth whichare collectively referred to as SIP servers. A SIP registrar associatesSIP users, e.g., names or identities called SIP user resource indicators(URIs) with their current locations, e.g., IP addresses. A SIP callproxy assists users in establishing calls, called dialogs in the SIPjargon, by handling and forwarding signaling messages among users, andother SIP servers. In practice, a physical host (SIP server) may assumemultiple logical roles, e.g., functioning both as registrars and callproxies.

SIP is a text-based request-response protocol, with a syntax verysimilar to HTTP, operating on the well-known ports such as tcp/udp 5060(for the standard SIP) and 5061 (for the secure SIP, SIPs). Hence SIPmessages are either of type request or response. The method field isused to distinguish between different SIP operations. The most commonmethods include REGISTER (for user registration), INVITE, ACK, BYE,CANCEL (these four used for call set-up or tear-down), SUBSCRIBE andNOTIFY (for event notification). Response messages contain a responsecode informing the results of the requested operations, e.g., 200 OK.The FROM and TO fields in an SIP message contains respectively the SIPURIs of the user where a request message is originated from (e.g., thecaller of a call) or destined to (e.g., the callee of a call). In thecase of a REGISTER message, both FROM and TO typically contains the SIPURI of the user where the request is originated. Other important fieldsinclude VIA and various identifiers and tags to string together varioustransactions and dialogs. More details can be found in Rosenberg et al.,RFC 3261, June 2002 which is incorporated herein by reference.

VoIP offers compelling advantages but it also presents a securityparadox. The very openness and ubiquity that make IP networks suchpowerful infrastructures also make them a liability. Risks includeDenial of Service (DoS), Service Theft, Unauthorized Call Monitoring,Call Routing Manipulation, Identity Theft and Impersonation, amongothers. Not only does VoIP inherit all data security risks, but itintroduces new vehicles for threats related to the plethora of newemerging VoIP protocols that have yet to undergo detailed securityanalysis and scrutiny. But just how serious are the threats posed toVoIP? Recently, there have been a string of attacks against either theVoIP infrastructure or end users. In one such incident, early June of2006, two men were arrested for fraudulently routing approximately$500,000 worth of calls illegally over the VoIP network belonging toNet2Phone, a Newark, N.J., VoIP provider. Fifteen Internet phonecompanies were reported as the victims of this attack. More recently,ISS posted a report about a Denial-of-Service vulnerability in the IAX2implementation of Asterisk, an open source software PBX. Thisvulnerability relates to the amount of time that a pending (but not yetauthenticated) call is allowed to exist in memory on the server. Newterms start to be coined over time just for VoIP attacks; “Vishing”, isnow used for phishing attacks using VoIP technology, or “Spit”, now usedfor spam over VoIP. Hence it is imperative for Service Providers towidely deploy scalable monitoring systems with powerful tools acrosstheir entire infrastructures such as to robustly shield their VoIPinfrastructure and protect their service. Passive packet monitoring andcapturing devices may be deployed in the underlying network hosting VoIPservices. In addition to capturing the standard layer-3 (IP) and layer-4(TCP/UDP) header information, it may be desirable to also capture aportion of layer-7 payload containing appropriate application protocol(SIP) fields. The captured packet header and payload information is thenprocessed and parsed for analysis and profiling. Unlike the layer 3/4header fields which generally have well-defined and limited semantics,the layer-7 application protocol such as SIP has a variety of fields,with rich semantics that are often context-sensitive and sometimes evenimplementation-specific. For example, with the SIP protocol itself, themeaning of the same fields may depend on the method used. Hence a majorchallenge in performing layer-7 protocol analysis and behavior profilingis to determine how to judiciously incorporate application-specificsemantics or “domain knowledge” to select appropriate set of keyfeatures to capture the essential behavior characteristics of theapplication in question.

Accordingly, there is a need for a general methodology forcharacterizing and profiling SIP-based VoIP traffic behavior.

SUMMARY OF THE INVENTION

A new algorithm is provided to automatically discover SIP servers, andto break down their logical functionality, e.g. registrars and callproxies. Exemplary traffic features are monitored at the server, entityand individual user levels in SIP traffic traces captured in anoperational network providing a commercial VoIP service. A new algorithmis also provided based on information entropy to profile the chosenmetrics over time and to generate alerts when any of the featuresdiverges from its historical trend. These algorithms and methodology areapplied to three different VoIP attacks generated in a controlled labenvironment to show their efficacy.

It is an objective of the invention to provide a methodology forcharacterizing and profiling SIP-based VoIP traffic behavior usingpassive traffic monitoring to identify anomalies, diagnose problems anddetect potential attacks on critical VoIP services and theirinfrastructure.

It is also an objective of the invention to identify anomalies,accurately diagnose problems on-fly and promptly detect and trace-backon-going attacks on critical VoIP service and their infrastructure.

It still another objective of the invention to provide a multi-level,progressively refined methodology that characterizes VoIP serviceactivity in real-time by extracting and profiling a large variety oftraffic features and metrics at three different levels: (i) server, e.g.broad-view of their behavior by monitoring and keeping statisticsrelated to only the message types such as request vs response, etc. (ii)entity, e.g. coarse-view of the servers activity by separating theirlogical roles into registrar} and call proxy; and (iii) individualusers, e.g. narrow-view of individual user activities such as typicalaverage duration and length of the calls, number of calls received andmade, etc.

It is yet another objective of the invention to provide a methodology tobalance the speed of profiling, the resource consumption, the desiredsophistication of behavior characteristics, and the level of security tobe offered, based on the specific objectives and needs of the VoIPOperator.

The results reported in this paper uses three SIP traces from the abovementioned network, referred to as trace segment 1 (13:55-14:30), tracesegment 2 (19:00-19:40) and trace segment 3 (19:55-20:30), respectively(the numbers within the parentheses indicate the start and end time ofthe traces) which are. They are of about 40 minutes or so long, capturedon a OC12 link between 13:00 h and 21:00 h within a single day. (Forprivacy concerns, the data are properly sanitized while preserving theneeded semantics for analysis.) Although the efficacy and efficiency ofthe claimed invention is demonstrated through these exemplary SIPtraces, one of ordinary skilled in the art would appreciate that theclaimed invention can be applied to any SIP traffic in general.

These and other implementations, their variations, applications, andassociated advantages and benefits are described in greater detail inthe attached drawings, the detailed description, and the claims. Thissummary does not purport to define the invention. The invention isdefined by the claims.

BRIEF DESCRIPTION OF DRAWINGS

So that the manner in which the above recited features, advantages andobjects of the present invention are attained and can be understood indetail, a more particular description of the invention, brieflysummarized above, may be had by reference to the embodiments thereofwhich are illustrated in the appended drawings.

It is to be noted, however, that the appended drawings illustrate onlytypical embodiments of this invention and are therefore not to beconsidered limiting of its scope, for the present invention may admit toother equally effective embodiments.

FIG. 1 illustrates a flow chart for detecting SIP servers.

FIGS. 2A and 2B illustrate exemplary statistics of SIP traffic tracescaptured in an operational network providing a commercial VoIP service.

FIG. 3 illustrates an exemplary multi-level methodology for profilingSIP network traffic.

FIG. 4 illustrates a flow chart for profiling SIP network traffic.

FIGS. 5A-5E illustrates an exemplary server level SIP network trafficbehavior in normal operational environments.

FIGS. 6A-6E illustrates an exemplary server entity level SIP networktraffic behavior in normal operational environments.

FIGS. 7A-7C illustrates another exemplary server entity level SIPnetwork traffic behavior in normal operational environments.

FIG. 8 illustrates yet another exemplary server entity level SIP networktraffic behavior in normal operational environments.

FIGS. 9A-9C illustrates still another exemplary server entity level SIPnetwork traffic behavior in normal operational environments.

FIGS. 10A-10C illustrates still another exemplary server entity levelSIP network traffic behavior in normal operational environments.

FIGS. 11A-11C illustrates an exemplary SIP network traffic anomaly.

FIG. 12 illustrates a flow chart for detecting SIP network trafficanomaly.

FIG. 13 illustrates an aspect of an exemplary algorithm for detectingSIP network traffic anomaly.

FIG. 14 illustrates another aspect of an exemplary algorithm fordetecting SIP network traffic anomaly.

FIGS. 15A-15F illustrates an exemplary SIP network traffic behavioragainst an exemplary call spam attack.

FIGS. 16A-16F illustrates an exemplary SIP network traffic behavioragainst another exemplary call spam attack.

DETAILED DESCRIPTIONS OF THE INVENTION

To identify the IP addresses associated with SIP servers using SIPtraffic traces, both application-layer (i.e., SIP) protocol informationas well as network/transport layer protocol information may be used. Aheuristics may be obtained by observing the role of SIP servers inSIP-based VoIP communications: typically users must register with SIPregistrars; and users call signaling must go through SIP call proxyserver. Hence the IP address associated with an SIP server willconsistently see a large number of SIP messages going through it (i.e.,with the said IP address as either the source or destination IPaddresses); furthermore, a large number of distinct FROM and TO fieldsin the appropriate SIP messages (e.g., INVITE, REGISTER, etc.) will beassociated with this IP address. An exemplary baseline algorithm for SIPcall proxy discovery is shown in FIG. 1 which examines the SIP INVITEmessages. An exemplary baseline algorithm for SIP registrar discovery isshown in FIG. 2 which examines the SIP REGISTER messages.

FIG. 1 illustrates a flow chart for detecting SIP servers. This processmay be adapted for a variety of SIP servers, including registrar, callproxy and the like. Here, one or more first tally count is produced bytallying a plurality of URIs associated with one or more source IPaddress in a plurality of SIP request messages (101). One or more secondtally count is produced by tallying a plurality of URIs associated withone or more destination IP address in a plurality of SIP requestmessages (102). One or more third tally count is produced by tallying aplurality of URIs associated with one or more source IP address in aplurality of SIP response messages (103). One or more fourth tally countis produced by tallying a plurality of URIs associated with one or moredestination IP address in a plurality of SIP response messages (104). ASIP server candidate corresponding to an IP address may then beidentified upon the corresponding first tally count exceeds a firstthreshold, the corresponding second tally count exceeds a secondthreshold, the corresponding third tally count exceeds a thirdthreshold, and the corresponding fourth tally count exceeds a fourththreshold (105). Once identified, one or more source port in theplurality of SIP response messages associated with the SIP servercandidate is compared to one or more pre-determined SIP service ports(106). A count is incremented upon each equal comparison (107). The SIPserver candidate is then identified to be a SIP server upon the countexceeding a fifth threshold (108).

An example for the processes 101-105 illustrated in FIG. 1 can be shownas the following baseline algorithm where SIP server call proxy may beidentified by examining the SIP INVITE messages. SIP server registrarmay be identified using a similar baseline algorithm by examining theSIP REGISTER messages.

for each m ∈ M do  if m.method == INVITE then   x = m.sourceIP; y =m.destinationIP;   from = m.FROM; to = m.TO;   if x ∉ IPSet then   x.Out_(FROM) = {from}; x.Out_(TO) = {to};    x.In_(FROM) = φ;x.In_(TO) = φ;   else    x.Out_(FROM) = x.Out_(FROM) ∪{from};   x.Out_(TO) = x.Out_(TO) ∪{to};   end if   if [| x.In_(FROM) |,|x.In_(TO) |,| x.Out_(FROM) |,| x.Out_(TO) |]   > [α,α,α,α]then   ProxyIP = ProxyIP ∪{x};   end if   if y ∉ I PSet then    y.In_(FROM)= {from};x.In_(TO) = {to};    y.Out_(FROM) = φ;y.Out_(TO) = φ;   else   y.In_(FROM) = y.In_(FROM) ∪{from};    y.In_(TO) = y.In_(TO) ∪{to};  end if   if [|y.In_(FROM) |,| y.In_(TO) |,| y.Out_(FROM) |,|y.Out_(TO) |]   > [α,α,α,α]then    ProxyI P = ProxyI P ∪{y}   end if end if end for

Here, for each IP address a in the SIP messages (either as the sourcewhere a is represented as x or as the destination where a is representedas y) the algorithm maintains four records, a.In_(FROM), a.In_(TO),a.Out_(FROM) and a.Out_(TO), which maintain, respectively, the set ofunique users (or rather their URIs) seen in the FROM and TO fields ofthe SIP INVITE messages received (represented as a.In) by or sent(represented as a.Out) from a. If the number of distinct users in eachof the four records exceeds a threshold alpha, then IP address a isincluded in the SIP call proxy candidate set ProxyIP. The threshold maybe determined, for example, by plotting In_(FROM) vs. In_(TO) andOut_(FROM) vs. Out_(TO) in a scatter plot, as shown in FIGS. 2A and 2Bfor an example.

The above algorithm ensures the diversity of callers (FROM) and callees(TO) in both the SIP INVITE messages originating and destined to a givenIP, therefore minimizes the chance of misclassifying a user in theforward mode while incoming INVITE messages are forwarded to anotherlocation, or similarly, a user in a conference mode. In both cases, theTO field of the INVITE messages will contain the URI (or its variants)of the forwarder. Hence the size of corresponding In_(TO) and Out_(TO)will be small (typically 1) and may be excluded from being misclassifiedby an appropriated set threshold (e.g. 10 or 20). However, thisalgorithm may misclassify a network address translation (NAT) box behindwhich there are many callers and callees as an SIP server. To avoid theambiguity of a NAT box from an SIP server, additional mechanisms need tobe incorporated into the baseline SIP server discovery algorithm. Anexemplary algorithm for the processes 106-108 illustrated in FIG. 1 canbe shown in the following example. For example, the source port of SIPresponse messages (e.g., responses to INVITE messages) originated fromeach IP (in the SIP server candidate set ProxyIP) may be verified tobelong to one of the SIP service ports (e.g., 5060, 5061 as defined inthe SIP RFC). If this is the case, the said IP address is considered anSIP server, otherwise it is rejected. This is because an SIP server doesnot initiate any call set up; it simply listens to service requests onits well-known service port and uses the service port as the source portin its response messages, whereas callers/callees behind an NAT box willuse a diverse set of source ports that are likely different from thewell-known SIP service ports.

The effectiveness of the baseline algorithm may be illustrated using thereal SIP traffic traces. FIGS. 2A and 2B illustrate statistics of SIPtraffic traces captured in an operational network providing a commercialVoIP service. FIG. 2A shows the numbers of unique FROM's vs. TO's in theSIP REGISTER messages received (i.e., In_(FROM) vs. In_(TO)) and sent(i.e., Out_(FROM) vs. Out_(TO)) by each IP address seen in the SIPtraces. Similarly, FIG. 2B shows the numbers of unique FROM's vs. TO'sin the SIP INVITE messages received and sent by each IP address seen inTrace II. Note that many hosts (i.e., IP addresses) may have the samenumber of FROM's and TO's, the labels on the side indicating the numberof such hosts including 201, 202, 203, 211, 212 and 213. In both cases,only two IP addresses server 1 and server 2 (which are the same two IPentity addresses 201/211 and 202/212 in FIGS. 2A and 2B) havesignificantly higher number than the remaining IP addresses 203 and 213,which have only one or very few distinct FROM's and TO's in a 30-40minute time interval. These two IP addresses are those of two SIPservers (in this case functioning both are registrars and call proxies)in the network, server 1 serving more users than server 2 in this 40segment SIP trace. Hence the baseline algorithm can effectively identifythe IP addresses associated with the SIP severs (registrars or callproxies) by appropriately setting the threshold (e.g., alpha=100depending on the time interval used).

Once the IP addresses associated with the SIP servers are identified,the behavior of SIP servers may be characterized and profiled byexamining the SIP messages going through them. The behaviors of SIPservers and their associated users may be characterized and profiled atthree levels—server, entity and (individual) user}—by introducing arange of features and metrics from coarser granularity to finergranularity in terms of the amount of application-specific (i.e., SIP)semantic information. This multi-level, progressively refinedmethodology balances the speed of profiling, resources required, desiredsophistication of behavior characteristics, and level of security, etc.based on the objectives and needs of an SIP-based VoIP operator. FIG. 3illustrates a multi-level methodology for profiling SIP network traffic.At the server level 301 only aggregate features and metrics aremaintained to provide a broad view of a SIP server behavior by examiningonly the message types 302 (e.g. request vs. response) into and out of aSIP server and extracting only coarse-grain user statistics information303. At the server entity level 311, the logical role of a SIP servermay be separated into registrar 321 and call proxy 313, as these twoseparate entities require a different set of features and metrics tocharacterize their respective behavior. Based on the SIP semantics, themethod field of a SIP message may be examined to attribute it to eitherthe SIP registrar or call proxy (e.g., a SIP REGISTER messages and itsresponse are part of a registrar activity while a SIP INVITE message andits response are part of a call proxy activity). Features and metrics314 and 315 may be computed for the corresponding registrars and callproxies. The activities of SIP registrars and call proxies may also becross-examined to build cross entity associations 316. At the individualuser level 321, the SIP messages may be attributed to individual usersfor maintaining statistics and features to characterize individual userbehaviors.

FIG. 4 illustrates a flow chart for profiling SIP network traffic. Here,a plurality of SIP messages associated with a SIP server is tallied toproduce a first message tally count (401). A plurality of SIP messagesassociated with the SIP server is then tallied according to a pluralityof distinct URIs to produce a plurality of second message tally counts(402). A user activity diversity (UAD) associated with the SIP server isthen calculated using normalized entropy according to the first messagetally count and the plurality of second message tally counts (403). Anexample for the processes 401-403 can be shown as the followingalgorithm applied to the server level 301 illustrated in FIG. 3. Theaggregate behavior of an SIP server may be characterized by maintainingtwo types of aggregate statistics and features: i) the numbers ofrequest and response messages received (i.e., fan-in) and sent (i.e.,fan-out) by each SIP server (and derivatively their correspondingratios) is counted over a given period of time T (say, 5 or 15 minutes);ii) the number of unique users (URIs) seen in the FROM and TO fields ofSIP messages, such as request messages, etc., is counted, and compute anaggregate user activity diversity (UAD) metric from the distribution ofsuch data over T. This UAD metric is computed as follows: Let m be thetotal number of SIP request messages over T, and n is the total numberof distinct users seen in the messages. For each unique user i, m_(i) isthe number of SIP messages with i in either the FROM or TO field of themessages. Then p_(i)=m_(i)/m is the frequency that user i is seen in theSIP messages. The user activity diversity metric, UAD, is then given bythe following equation:

${UAD}:={{{( {- {\sum\limits_{i}\;{p_{i}\log\; p_{i}}}} )/\log}\; m} \in \lbrack {0,1} \rbrack}$where the numerator is the entropy of a histogram P={p_(i)}, while thelog m is its maximum entropy—the ratio of the two is the standardized(or normalized) entropy or relative uncertainty (RU). UAD thus providesa measure of “randomness” of user activities as captured by thedistribution {p_(i)}: for n>>1, if UAD approximately equals 0, a fewusers dominate the SIP activities (in other words, they appear in mostof the messages), whereas UAD approximately equals 1 implies that p_(i)is on the order of 1/m and thus each user only appears in a few numberof SIP messages (hence overall the user activities appear random). Theintuitions for these two types of aggregate statistics and features areas follows: As SIP is a request/reply-based protocol, the ratio betweenthe numbers of request/reply messages is expected to bounded and stable.Moreover, since each user must periodically register or re-register witha SIP server, and calls are initiated by human users, the number of SIPrequests and the number of users are unlikely to exhibit hugevariations, and user activities should in general be quite diverse andrandom. In the next section we see that our intuitions are born out bythe results we obtained using the real SIP traces.

Another example for the processes 401-403 can be shown as the followingalgorithm applied to the server entity level 311 illustrated in FIG. 3.Using the method field of SIP messages, registrar-related messages(e.g., the REGISTER messages and their responses) may be separated andused to generate statistics and features for registrar behaviorprofiling. Similar to the server level analysis, aggregate statisticsregarding the numbers (and ratios) of REGISTER and otherregistrar-related requests and responses received and sent by aregistrar are maintained. In terms of user activities, the number (andlist) of users that are successfully registered is maintained. A similarUAD metric with respect to the registrar may then be calculated. Inaddition to these aggregate statistics and features regarding themessage types and user activities, more detailed registration analysismay also be performed. The response codes in the response messages maybe examined to maintain statistics about the numbers of successful andfailed registrations. The registration periods of users (i.e., the timelapses between two consecutive REGISTER messages from the same users)and the inter-arrival times of any two consecutive REGISTER requestmessages (from different users) may be calculated. From the former the(average) registration period of the registrar may be calculated. Fromthe latter a (fitted) model for the user REGISTER request arrivalprocess may be derived. Together they not only reveal the configurationof the registrar but also the temporal behavior of the registrar.

Yet another example for the processes 401-403 can be shown as thefollowing algorithm applied to the server entity level 311 illustratedin FIG. 3. By analyzing the SIP messages related to call activities(e.g., SIP messages with the INVITE, BYE methods and their responses),statistics and features for call proxy behavior profiling may begenerated. Similarly as before, aggregate statistics regarding thenumbers and ratios of various call requests (INVITE, BYE CANCEL, etc.)and their responses received and sent by a registrar may be maintained.Several UAD metrics regarding the aggregate user call activities may bemaintained. For example, UAD_caller, UAD_callee and UAD_caller-callee,which measures the UAD of callers, callees and caller-callee pairs. Eachof these metrics is computed using the equation:

${UAD}:={{{( {- {\sum\limits_{i}\;{p_{i}\log\; p_{i}}}} )/\log}\; m} \in \lbrack {0,1} \rbrack}$with appropriate defined parameters: m is the number of SIP call requestmessages (SIP INVITE, BYE and CANCEL requests, and i) for UAD_caller,m_(i) is the number of SIP call request messages with user i in the FROMfield, ii) for UAD_callee, m_(i) is the number of SIP call requestmessages with user i in the TO field, and iii) for UAD_caller-callee,m_(i) is replaced by m_(ij) where m_(ij) is the number of SIP callrequest messages with user i in the FROM field and user j in the TOfield. Furthermore, a more detailed call analysis may be performed tomaintain various call statistics and features of a call proxy. Theseinclude the number of on-going calls, completed calls (calls ended byBYE only), cancelled calls (calls ended by CANCEL only), call re-invites(an INVITE request followed by another INVITE request from the samecaller to the same callee before the call is ended), and so forth, in agiven time period. Statistics (average, standard deviation ordistribution) regarding call durations and call request arrival ratesmay also be computed.

When data are available, SIP messages among different entities (e.g.,between registrars and call proxies, and among call proxies) may becorrelated to generate a cross-entity and network-wide view of the SIPtraffic activities. For example, by correlating the registrationinformation from a registrar and its associated call proxies, statisticsand features regarding calls made among registered users of theregistrar, from the registered callers to other callees (not registeredwith the registrar), from other callers (not registered with theregistrar) to the registered callees, and from other callers to othercallees may be derived. The relationship among call proxies may also becharacterized.

Still another example for the processes 401-403 can be shown as thefollowing algorithm applied to the server entity level 311 illustratedin FIG. 3. If needed, statistics and features regarding the individualuser activities may be maintained. For example, from the user callactivities the (typical or average) number of calls made or receiver byeach user u may be maintained, and the diversity of calleesUAD^(u)_callee of the calls made by the user as well as the diversity ofcallers UAD^(u)_caller of the calls received by the user u may becomputed. Other statistics such as (average) call durations may also bemaintained. FIGS. 5A-5E illustrates SIP network traffic behavior innormal operational environments. Here, the general profiling methodologypresented in the previous examples is applied to analyze the SIP trace2, corresponding to server 1, to illustrate the characteristics of SIPtraffic in a real VoIP. As an example, it is shown following the serverlevel profiling 301 that in normal operational environments SIP trafficbehavior tends to be very stable both in terms of various SIP messagetypes, user registration, call and other related activities. FIGS. 5A-5Eillustrates an exemplary server level SIP network traffic behavior innormal operational environments. FIG. 5A shows the numbers of requestand response messages received (denoted as REQin and RESin respectively)and sent (denoted as REQout and RESout respectively) by server 1 over5-minute time intervals in segment 2 of the SIP traces. The first andlast 5 minutes of the segment are removed to avoid the boundary effect.FIG. 5B shows, respectively, the ratios of REQin vs. RESout, REQout vs.RESin and REQin vs. REQout over the same 5-minute time intervals. It canbe seen that overall the total numbers of request and response messagesreceived and sent by the SIP server do not vary significantly. Inparticular, for every one request message received/sent by the SIPserver, on the average there is approximately one response messagesent/received by it—this is generally to be expected. There are roughlytwice as many request messages received by the SIP server than sent byit. This is primarily due to the REGISTER messages which comprise alarge portion of the total request messages received by the SIP server.Unlike many SIP request messages of other methods (e.g., INVITE,SUBSCRIBE, a REGISTER request message does not trigger the SIP server togenerate another request message except a response message. The SIPrequest messages may be broken down based on the method type and counttheir numbers over 5-minute time intervals. FIG. 5C shows theproportions of request messages of each method type received by the SIPserver. FIG. 5D shows the proportions of request messages of each methodtype sent by the SIP server. It can be seen in FIG. 5C, REGISTER requestmessages consist of nearly 60% of the total request messages received bythe SIP server, while SUBSCRIBE request messages consist of 40% of them.In particular, there is no NOTIFY request messages received by the SIPserver. In contrast, in FIG. 5D, the NOTIFY messages comprise of 90% ofthe total request messages sent by the SIP server, while there is noREGISTER request messages at all. More in-depth examination of theSUBSCRIBE messages received and NOTIFY messages sent by the SIP serverreveals that there is approximately a one-to-one correspondence betweenthe SUBSCRIBE messages received and NOTIFY sent: this is to be expected,as a SUBSCRIBE received by the SIP server would trigger one (and perhapsa few more) NOTIFY messages sent by the SIP server. In both the requestmessages received and sent by the SIP server, call-related SIP requestmessages such as INVITE, BYE and CANCEL consist of only a small portionof the total request messages received/sent by the server. FIG. 5E showsthe user activity diversity (UAD) metric of the total SIP messages (bothreceived and sent) by the SIP server over 5-minute time intervals, aswell as those for SIP request messages received and sent separately. Itcan be seen that the UAD metrics are close to 1 over all 5-minute timeintervals and they are fairly stable. This is primarily due to theperiodic exchanges of the REGISTER, SUBSCRIBE and NOTIFY messages andtheir responses between the SIP server and users. Results show that theaggregate SIP traffic behavior is in general fairly stable and theaggregate statistics/features chosen in the profiling methodologyprovides a good summary of these stable characteristics. The sameobservations also hold true for server 2 (which handle a relativelysmaller portion of SIP messages in trace segment 2) as well as for tracesegment 3 (where server 2 handles a large portion of SIP messages whileserver 1 handles a relatively smaller portion of them).

As another example, following the server entity level profiling 314, theREGISTER request messages and their responses of server 1 (functioningin the role of a registrar), and in particular, how REGISTER messagesare generated by users may be examined. In FIG. 5C, it can be shown thatREGISTER messages consist of 60% of the total request messages receivedby the SIP server (registrar). Moreover, the ratio of the number ofREGISTER request messages vs. their responses is approximately 1. FIGS.6A-6E illustrates an exemplary server entity level SIP network trafficbehavior in normal operational environments. FIG. 6A shows that the useractivity diversity metric for the REGISTER request messages is close to1, indicating that there are no individual users who dominate thegeneration of REGISTER messages. In FIG. 6B, the number of unique usersseen in the FROM field of the REGISTER messages is plotted over 5-minutetime intervals as well as over 10- and 15-minute intervals. The totalnumber of unique users seen in the entire segment of trace 2 is 17797,all of which are successfully registered. Hence on average there is oneREGISTER message per user in each 15-minute interval. To furtherillustrate how REGISTER messages are generated, the time lapses betweentwo consecutive REGISTER messages from each user may be calculated, thedistribution of which is shown in FIG. 6C. The distribution clearlyreveals that users generate REGISTER messages roughly periodically witha mean of 15 minutes. In FIG. 6D, the distribution of the inter-arrivaltimes between two consecutive REGISTER messages from two different usersis plotted. The distribution may be well fit into an exponentialdistribution of the form p(x)=λe^(−λx), where λ=0.27. Hence it can beseen that the number of REGISTER messages seen by the SIP serverregistrar follows approximately a Poisson process, and the number ofdistinct users seen by the SIP server registrar in a time interval oflength T≦15 min is roughly x times T. Hence it can be seen on theaverage around 6000 number of users in a 5-minute interval and around12000 in a 10-minute interval, as shown in FIG. 6B. FIG. 6E is thescatter plot showing the number of REGISTER requests vs. the number ofresponses per user over 5-minute intervals. It can be seen that themajority of users send one REGISTER request every 5 minute whilereceiving one response. Several users receive more than severalresponses} back. In addition, a few users send up to 6 requests beforegetting one response back. This is likely due to possible registrationfailures, as the responses typically contain 4xx response code such asxxx and xxx. Following up on these failed user registration attempts, itis found that these users are eventually able to successfully registerby re-sending REGISTER requests in a later time (typically after 15minutes) that results in a successful response with the response code“200 OK”. FIGS. 7A-7C illustrates another exemplary server entity levelSIP network traffic behavior in normal operational environments. Asshown earlier, SUBSCRIBE messages from users constitute nearly 40%requests received by the SIP server, and NOTIFY messages about 90% ofrequest messages sent by the SIP server. Each SUBSCRIBE message from auser is followed by one or more NOTIFY messages from the SIP server tothe same user (see FIG. 7A for the scatter plot showing the number ofSUBSCRIBE messages sent vs. NOTIFY messages received per user in5-minute intervals). FIG. 7B shows the distribution of the time lapsesbetween two consecutive SUBSCRIBE messages from each user, and FIG. 7Cshows the distribution of the inter-arrival times of two consecutiveSUBSCRIBE messages from any users. These distributions are very similarto those of the REGISTER messages. The SUBSCRIBE messages are sentperiodically by users and often follow the REGISTER messages of theusers. Although SUBSCRIBE can be used by users to subscribe to manypossible events, some specific to other users (e.g., events related toon-going dialogs at the other calling parties), the large number ofSUBSCRIBE messages and their regularity indicates that these SUBSCRIBEmessages are sent by users to subscribe to some server/system resourcessuch as voice mailboxes.

As still another example, following the server entity level profiling315, call proxy and user call behavior characteristics may be analyzed.FIGS. 8 and 9A-9C illustrates still another exemplary server entitylevel SIP network traffic behavior in normal operational environments.FIG. 8 shows the numbers of various call-related SIP request messagessuch as INVITE, BYE, CANCEL and ACK sent/received by the SIP serverfunctioning as a call proxy) over 5-minute intervals. Comparing with thenumber of REGISTER, SUBSCRIBE and NOTIFY messages, call-related messagesconsist of a much smaller portion, indicating that while there are alarge number of users (or, SIP phone devices) in the network, only avery small number of the users actually make phone calls in each5-minute period. This observation is further confirmed in FIG. 9A whichshows the number of unique callers (users seen in the FROM field ofINVITE messages) and callees (users seen in the TO field). Recall thatthere is a total of 17797 unique users in the trace segment. FIG. 9B isa scatter plot showing the number of calls made vs. calls received peruser over 5-minute intervals. Again it can be seen that at individualuser level, the numbers of calls made and received are generally verysmall and consistent. In terms of diversity of calls made by users, FIG.9C shows the UAD metrics of callers (FROM's), callees (TO's) andcaller-callee pairs (FROM-TO's) as defined above. It can be seen thatthe call activities are fairly random, not dominated by any particularuser either as caller or callee. FIGS. 10A-10C illustrates still anotherexemplary server entity level SIP network traffic behavior in normaloperational environments. The number of various call types (on-going,completed, not-established (i.e., failed or canceled)) over 5-minuteintervals is shown in FIG. 10A. FIG. 10B shows the distribution of callinter-arrival times, and FIG. 10C shows the duration of completed calls(and cancelled calls). It can be seen that the number of calls in atypical 5-minute interval is fairly small, and the call arrival processis approximately Poisson with approximately exponentially distributedcall inter-arrival times. Call duration typically lasts between 1-3minutes, while canceled calls tend to very short. These statistics aresimilar to traditional telephony, indicating that these call activitiesare human-generated.

The exemplary general profiling methodology presented above may be usedto identify anomalies that may be caused by performance problems orimplementation flaws in a VoIP service or the underlying network. A casestudy may be used to illustrate the efficacy—a case uncovered in theanalysis of the SIP traces from an operational VoIP network. FIGS.11A-11C illustrates an exemplary SIP network traffic anomaly. Asdescribed above, it can be seen that overall the numbers of SIP REGISTERrequest and response messages and their ratios (over 5-minute intervals)stay fairly stable, and this can be mainly attributed to the fact thatusers generate REGISTER messages periodically and these messages aregenerated randomly from the users. These observations hold almost all5-minute intervals for both servers in the traces except for one5-minute interval of server 1 in trace segment 1, where an anomaly isfound. As evident in FIG. 11A, the number of REGISTER messages receivedby server 1 (REQin) in the very first 5-minute interval in this tracesegment is significantly larger than in other time intervals, and whilethe number of the responses sent by the server also increasesslightly—in particular, the ratio of the numbers of requests vs.responses increases drastically. To figure out what caused this anomaly,an in-depth analysis may be performed of the SIP messages in thisanomalous 5-minute interval. FIG. 11B shows the number of REGISTERmessages received by server 1 vs. the responses generated by it in eachsecond of the anomalous 5-minute interval. It can be seen that betweenaround the 100th second to 160th second of this 5-minute interval, thenumber of REGISTER requests from users shots up quickly, while theresponses returned by the server first dips for about 50-60 secondsbefore it shots up also, catching up with the number of REGISTERrequests, after which everything returns to the norm. FIG. 11C is ascatter showing the number of REGISTER requests generated vs. number ofresponses received per user in the 1-minute time period from the 100thsecond to 160th second. To better illustrate the number of data pointsoccupying a particular integer-valued grid (x, y); the data points maybe perturbed slightly around it at random. It can be seen that insteadof the normal one REGISTER request and one response per user, many userssend from 2-7 REGISTER requests while receiving one or two responses.Closer investigation may reveal that the problem is caused by the SIPserver not responding to the user registration requests immediately,which triggers the users to repeatedly re-transmit the requests in ashort time span (within a few seconds) until it either gives up orreceives a response back—either with response code 404 (Not Found) or408 (Request Timeout) or eventually with response code 200 (OK). Sinceall these users were eventually able to successfully register with theSIP server, the surge of the REGISTER requests is unlikely caused bysome kind of denial-of-service attacks with spoofed or frivolousREGISTER messages. That the SIP server failed to respond to the userregistration requests in a timely fashion may be caused by delay or slowresponse from some remote (user/call) database with which the SIP serverwas interacting. This problem points to a implementation flaw in the SIPclient software: when a registration request times out, the clientimmediately retransmits the request, thereby causing a surge of requestsand thus making the problem worse. A better implementation solutionwould have been to use an exponential back-off mechanism to handle theretransmission of the registration requests. This SIP traffic anomalyfound in this case study may be easily detected using the generalprofiling methodology described above: by tracking the number ofREGISTER messages and the ratio of REGISTER messages and their responsesover time (e.g., via an exponential averaging), a simple threshold-basedchange detection mechanism may be applied to detect the anomaly.

FIG. 12 illustrates a flow chart for detecting SIP network trafficanomaly. Here, a first and second parameters are calculated according toa feature function at a plurality of time increments (1201). At one ormore of the plurality of time increments, an alert level is incrementedand the first parameter is locked upon the second parameter exceeding afirst threshold (1202). At one or more of the plurality of timeincrements, the alert level is decremented upon the second parameterbeing exceeded by a second threshold (1203). The first parameter isunlocked upon the alert level being exceeded by a first level (1204).Then an anomaly is reported upon the alert level exceeding a secondlevel (1205). As an example, an ensemble of statistics and features maybe produced over time: for each statistics/feature, a time series isgenerated. Sudden changes or deviations from expected behavior in one ora subset of the statistics/feature time series may signify anomalies.Different VoIP attacks may trigger a different set or subset ofstatistics/features to exhibit sudden changes or deviant behaviors.

FIG. 13 illustrates an exemplary algorithm of the process 1201 fordetecting SIP network traffic anomaly. The exemplary algorithm is forbase-lining a deviation during a learning period: inputs are featurevalues f(t) at time instants tε[0−T_(learn)] and the following timewindows: T₁, T₂ and T_(learn), where T₁+T₂<T_(learn). Output is ameasure of maximum possible deviation: α. Here, during a from timewindow [0−T_(learn)], a feature function is base-lined and an estimateof the maximum possible deviation is obtained under normal circumstances(1201). The average value of the feature function f, may be calculatedover a sliding window T₁ where T₁<T_(learn). As an example, ExponentialWeighted Moving Average (EWMA) may be used with a β=2/(T₁+1). The EWMAof a feature function at a time t may be calculated as: EWMA(t)=βEWMA(t−1)+(1−β f(t) (1301). Thus, the EWMA of the feature function maybe the predicted value and a first parameter “slope” may be calculatedas: s(t)=|f(t)/(EWMA(t))−1| (1302). Over another window T₂, whereT₁+T₂<T_(learn) the first parameter “slope” may be averaged such thatfor every time t in the period [T₁+T₂<T_(learn)], a average slope may becalculated as s_(avg)(t)=1/T₂Σ^(t) _(t−T2) s(t) (1303). At a time t+1,an instantaneous deviation may be calculated as a second parameter fromits average as: d(t+1)=s(t+1)/s_(avg)(t), or:

$\begin{matrix}{{d(t)} = \frac{s(t)}{s_{avg}( {t - 1} )}} & (1305)\end{matrix}$The maximum of this deviation in the time period [(T₁+T₂+1)−T_(learn)]may be calculated as a first threshold as:

$\begin{matrix}{\alpha = {\max_{t = {T_{1} + T_{2} + 1}}^{T_{learn}}{d(t)}}} & (1306)\end{matrix}$

FIG. 14 illustrates an exemplary algorithm of the process 1202-1205 fordetecting SIP network traffic anomaly. Here, after the learning periodis over, the “slope” s(t) may be monitored and if it is a times greaterthan the average slope s_(avg)(t−1), or if the second parameter d(t)exceeds the first threshold α (1401), then an alert level is increased(1402). Otherwise, if the second parameter d(t) is less than a secondthreshold α′ (1403), the alert level is decreased (1404). The secondthreshold α′ may be calculated as a sum of the first threshold α and anoffset, or as a multiplied product of the first threshold α and afactor, or using some other functional relationship based on the firstthreshold α. The first and second threshold may also be configurable tofine tune the algorithm. In some example, α and α′ may be chosen to bethe same. If an alert was increased, then the values for feature averageand average slope are locked-in (1402), i.e., can be updated (1406,1407) only when the alert value is reduced to be less than a first level(1405). The first level may be set to zero or other suitable level.False alarms are avoided by having multiple alert levels. In an example,four alert levels may be implemented: Green (alert=0), Yellow (alert=1),Red (alert=2) and Black (alert=3), where each represents a system incontinually increasing alert levels. The state of a feature functionstarts in Green phase at initialization and may be changed progressivelyacross the alert levels on each alert.

This reporting phase is used for reporting the suspicious elements of afeature that are contributing to the anomaly. The reporting phase isapplied (1409) only when the alert level exceeds a second level, e.g.the alert level is changed to Black (1408). For instance, if aparticular IP address starts sending multiple Registration requests aspart of a voice spam or DoS attack, then the UAD_caller would decreaseand this anomalous address may be isolated as follows. First, the last“clean histogram”, i.e., the histogram corresponding to the last Greenstate, is maintained that has been seen for the feature. Next, when thefeature's phase is changed to Black, the current histogram may becompared with the last clean one to obtain the elements that contributethe most to the change in the histograms. In particular, the set ofelements S may be reported that contribute to the top 5 percentile ofthe change in histogram. This is done by calculating the RelativeEntropy Σ_(i)|H_(i) log(H_(i))/log(h_(i)))| of the current histogram Hwith respect to the last clean one h and sorting the elements accordingto the value they contribute to the relative entropy. Thus, defining themaximum element as: s_(i)=max_(i)

_(H) |H_(i) log(H_(i))/log(h₁))|, and similarly the second maximumelement s₂ and so on up to the last element S_(n), the set S may bedefined as: {s₁, . . . , s_(i): Σ^(i) _(j=1) s_(j)<0.05 Σ^(n) _(j=1)s_(j)}.

As an example, some common potential attacks on VoIP services mayinclude DoS and DDoS attacks on VoIP infrastructure or users, VoIP spam,and worms that exploit VoIP protocols to spread. Such an attack mayintroduce either a volume surge, a sudden change or deviation in theratio/distribution statistics or metrics (e.g., randomness) in one ormultiple feature functions. Consider an example call spam attack,defined as when a spammer generates many calls, most likely in anautomated fashion towards several unsuspecting callees, e.g., automatedcalls made by telemarketers simultaneously to many callees advertising aproduct. Thus, by varying the following parameters, a spammer maygenerate a variety of attacks:

(1) number of callers per spammer IP address;

(2) whether the IP addresses are legitimate or not;

(3) number of IP addresses and;

(4) volume of spam calls.

One such example is a High volume spam: One caller per legitimate IPaddress from one or few addresses sends large number of calls to randomcallees. Another such example is a Low volume spam: One caller perlegitimate IP address from one or few addresses sends moderate number ofcalls to random callees. Yet another example is: Many callers perlegitimate IP address from one or few addresses send a moderate numberof calls to random callees.

The efficacy and efficiency of the above described detection algorithmmay be validated with a test bed. An exemplary test bed may consist of ahigh speed packet analyzer, which can parse layer-7 payloadsoff-the-wire from network links as fast as 2.5 Gbps. The VoIP packetsbelonging to the same call may be uniquely identified by their Call-id,using which the control packets (SIP) belonging to the same call may begrouped (sessionalized) into unique sessions. The analyzer may emit anannotated vector per packet that identifies the session ID of the packetalong with other details such as caller and callee URI and IP address,type of packet and so on. These vectors may then be processed by theexemplary anomaly detection module, such as described in FIGS. 12, 13and 14, which performs base-lining of the traffic and emits alerts uponidentifying an anomaly. In an example, the test-bed consists of twomachines, connected via an OC-48 link (2.5 Gbps). The trace may bereplayed from one machine while the other one is configured to sniffpackets off-the-wire and runs the packet analyzer as well as theexemplary anomaly detection module. Each machine has two Intel® Xeon™CPU 3.40 GHz processors and runs the Linux kernel 2.4.21. The packetanalyzer and anomaly detector are both single-threaded 32-bit processesand hence the amount of memory available to either of them is the Linuxconfigured per process maximum of 4 Gbytes. Through performanceexperiments, the packet analyzer is found to be capable of maintaining aline-rate of 2.5 Gbps while processing VoIP packets up to a maximum of600,000 concurrent calls with new calls arriving at 1000 calls/second.

FIGS. 15A-15F and 16A-16F illustrates exemplary SIP network trafficbehavior against exemplary call spam attacks. The efficacy andefficiency of the exemplary anomaly detection module, such as describedin FIGS. 12, 13 and 14, against these exemplary call spam attacks aredemonstrated. A 3-minute sample of clean traffic trace is merged with asynthetic call spam attack towards the end of the trace. As an example,one existing caller URI and IP address from the trace is selected as thespammer and multiple SIP requests are generated from this caller towardsrandomly generated callees. Two exemplary attacks are generated:

(1) a high-volume call spam that lasts a duration of 25 seconds, withnew calls generated in the first 10 seconds at the rate of 100calls/second to yield a total of 1000 spam calls in the trace and (2) alow-volume spam, consisting of only 10 calls generated by the spammer inthe same time duration of 10 seconds. Each spam call begins with anInvite sent towards a random callee and 100% of the callees respondfavorably to the caller by proceeding to take the call. Hence, the spamtraffic also consists of Ringing and OK/200 Response packets that aresent in the other direction i.e., from callee to caller. The SIPhandshake is completed by the caller sending an ACK in response. Eachspam call is generated to last the same duration of 15 second, thespammer may transmit the same automated message to each caller. As anexample, none of the callees hang up on the call before it is ended bythe callee, thereby each spam call lasts the same time duration. Eachcall ends with the callee sending a Bye request to which the callerresponds with a Bye-Ack. The exemplary anomaly detection module isconfigured with a time slot of 2 seconds, where the learning periodT_(learn) lasts for 40 time slots. The averaging time periods T₁ and T₂are 5 and 15 slots respectively. FIG. 15 shows the efficacy of theexemplary base-lining algorithm such as described in FIG. 13, since eachfeature function can be observed to be stationary before the attack. Theattack is detected almost instantaneously around time slot 60 when thefeatures of total requests, total responses and total unique callee URIsreach the Black (Alert value=3) alert stages. Further note in FIGS.15D-15F that the normalized entropy, or relative uncertainty (RU), ofhistograms for the caller (denoted as client) IPs and URIs and callduration are dominated by the spammer and thereby the UAD for thesehistograms exhibit sharp decreases around the beginning of the attack.During the time when the alerts for these features is at Black stage,the current histogram is compared with the last clean histogram i.e.,the one at time slot 60 and are also able to obtain the caller URI andcaller IP involved in the attack (not shown in figures). Also there aretwo peaks observed in FIG. 16A where the first peak occurs close to thebeginning of spam and consists of the flood of Invites and the secondpeak occurs close to the end of the spam consisting of Bye packets.Since, the first call belonging to the call spam completes 15 secondsafter the beginning of the call spam, the histogram for call durationexhibits anomalies much later than other features i.e., around timeslot=70, when the call duration of spammers begins to dominate thehistogram. Moreover, the exemplary anomaly detection method is able toextract the duration of each spammer as the correct value of 15 seconds.The efficacy of the exemplary anomaly detection in detecting even thelow volume attacks is highlighted in FIG. 15 which shows the performancein the presence of the low volume call spam. In this case, the spammeris able to hide within the background traffic quite well as none of thevolume features of total number of requests, total number of responses}or number of callee URIs exhibits any significant change during the spamperiod. However, the intrinsic behavior of the spammer of generatingmultiple requests from the same client URI and IP address results in thedetection of the attack via the features that track user behavior.Hence, the UAD for callee URI and IP address exhibit three consecutivealerts, leading to the extraction of the suspect URI and IP addressaround time slot 63.

1. A method for session initiation protocol (SIP) server identificationcomprising: tallying a plurality of distinct uniform resource indicators(URIs) associated with one or more source IP address in a plurality ofSIP request messages to produce one or more first tally count; tallyinga plurality of distinct URIs associated with one or more destination IPaddress in the plurality of SIP request messages to produce one or moresecond tally count; tallying a plurality of distinct URIs associatedwith one or more source IP address in a plurality of SIP responsemessages to produce one or more third tally count; tallying a pluralityof distinct URIs associated with one or more destination IP address inthe plurality of SIP response messages to produce one or more fourthtally count; and identifying a SIP server candidate corresponding to anIP address upon the corresponding first tally count exceeds a firstthreshold, the corresponding second tally count exceeds a secondthreshold, the corresponding third tally count exceeds a thirdthreshold, and the corresponding fourth tally count exceeds a fourththreshold.
 2. The method of claim 1 further comprising: comparing one ormore source port in the plurality of SIP response messages associatedwith the SIP server candidate to one or more pre-determined SIP serviceports; incrementing a count upon each equal comparison; and identifyingthe SIP server candidate to be a SIP server upon the count exceeding afifth threshold.
 3. The method of claim 1 further comprising: examiningone or more method field of one or more SIP messages associated with theSIP server; and identifying a SIP server type according to the one ormore method field.
 4. The method of claim 3 wherein the one or moremethod field comprises a register and the SIP server type comprises aregistrar.
 5. The method of claim 3 wherein the one or more method fieldcomprises an invite and the SIP server type comprises a call proxy.